Locked Out of Hotel Wifi by One Button

Written by: Julius Serrano

The year was 2010. I'm in Penang, Malaysia, running a full-day accessibility workshop for a room of more than a hundred people. Lovely hotel. First day goes well. That evening, I want to do the most basic thing possible: connect to the wifi.

The staff tell me, easy, just go to this page, fill in your details, hit Submit.

I try. Tab, tab, tab, through the form fields, no problem. Then I get to the button. And nothing happens. No matter how many times I press Enter, nothing. Because, and I only found this out after calling reception, the Submit button could only be activated with a mouse. I don't use a mouse or trackpad at all, I navigate entirely by keyboard, since I can't see the on-screen pointer to move it and click where I need to.

So I called reception. Someone came up, clicked the button for me, wifi connected.

Here's the part that still makes me laugh. The wifi had the memory of a goldfish. Every single time I wanted to reconnect, same page, same unreachable button, same phone call to reception. And because shifts change, I ended up having the exact same conversation with a rotating cast of hotel staff, sometimes more than once a day. "Hi, sorry, it's the blind guy from the workshop again, still can't click the button."

I was teaching a room full of people about digital accessibility all day, then spending my evenings living the exact problem I'd just taught about, at the hotel hosting the workshop.

Keyboard Accessibility Failures: Why They Still Happen

You might be thinking, surely by 2026 this doesn't happen anymore. Mostly, things have improved. But keyboard accessibility is still one of the most common things we find broken when we test a website or app today. Often the cause is simple: a button built as a styled <div> or <span> with a click handler, rather than a real <button> element, looks and works fine with a mouse, but keyboards don't know it's there at all.

This isn't a grey area or an advanced technical nuance. It's covered by WCAG Success Criterion 2.1.1, Keyboard, one of the most fundamental accessibility requirements there is. It sits at Level A, the baseline conformance level every website is expected to meet, not an optional extra for advanced sites. In plain terms, it requires that everything a mouse can do, a keyboard can do too. A hotel wifi login page failing this in 2010 wasn't a subtle miss. It was a failure of the most basic requirement on the list.

Who Needs Keyboard Accessible Content

This isn't just a blind-user issue, even though that's the story that illustrates it here. Keyboard accessibility matters for a lot of people. Someone with a motor condition like Parkinson's or arthritis, who can't reliably control a mouse. Someone using a switch device or other adaptive input method, which often doesn't work the way a mouse does either. Someone with a temporary injury, a broken wrist, a sprained hand, using a keyboard because a mouse isn't an option right now. Even power users who navigate faster by keyboard out of pure habit. A button that only works with a mouse quietly locks out a lot more people than most teams realise.

How to Test Keyboard Accessibility on Your Website

Here's a simple test anyone can do on their own website, no tools, no technical background required. Unplug your mouse, or just don't touch it, and try to use your site using only Tab, Shift+Tab, and Enter. Can you reach every link, button, and form field? Can you actually activate all of them? If you get stuck anywhere, that's a real barrier, not a hypothetical one, and it's exactly the kind of thing a screen reader user, or someone in a hotel room fifteen years ago, would get stuck on too.

The Real Cost of Skipping Keyboard Accessibility

I still test for exactly this. Because somewhere out there, right now, someone's probably on the phone to a hotel reception desk, for the third time that day, asking someone to click a button for them.

Want to know how your own site holds up? We'll test it and tell you straight. Get in touch with Tactile.